Method and apparatus for sharing secure communications

ABSTRACT

A method and apparatus for controlling use of content by sharing secure communications. A user device receives a challenge token from a first server and forwards the challenge token to a second server in association with a request for use of content. A signature of the challenge token is analyzed to determine an origin of the challenge token and the request is authorized by a second server to use the content if the first server is related to the second server.

RELATED APPLICATION DATA

[0001] This application is a Continuation of application Ser. No.10/046,670 filed Jan. 16, 2002, which claims benefit of priority toProvisional Application Serial No. 60/261,803 filed on Jan. 17, 2001 andis a Continuation-In-Part of application Ser. No. 09/649,841 filed Aug.28, 2000, the entire disclosures of all of which are incorporated hereinby reference.

FIELD OF THE INVENTION

[0002] The invention relates to distribution of digital content, andmore particularly, to a method and apparatus for facilitatingdistribution of protected documents displayed with the rendering engineof a standard application program, such as an Internet Web Browser.

BACKGROUND OF THE INVENTION

[0003] The Internet is a worldwide network of computers linked togetherby various hardware communication links all running a standard suite ofprotocols known as TCP/IP (transmission control protocol/Internetprotocol). The growth of the Internet over the last several years hasbeen explosive, fueled in the most part by the widespread use ofsoftware tools (known as “browsers”) which allow both HTML (hypertextmarkup language) viewing and HTTP (hypertext transfer protocol)navigation. Browsers allow a simple GUI (graphical user interface) to beused to communicate over the Internet. Browsers generally reside on thecomputer used to access content on the Internet, i.e. the clientcomputer. HTTP is a component on top of TCP/IP and provides users accessto documents of various formats using the standard page descriptionlanguage known as HTML and more recently XML (extensible markuplanguage) and XHTML (extensible hypertext markup language), areformulation of HTML into XML. The collection of servers on theInternet using HTML/HTTP has become known as the “World Wide Web” orsimply the “Web.”

[0004] Through HTML, XHTML, and interactive programming protocols, theauthor of content is able to make the content available to others byplacing the content, in the form of a Web page, on an Internet Webserver. The network path to the server is identified by a URL (UniformResource Locator) and, generally, any client running a Web browser canaccess the Web server by using the URL. A client computer running abrowser can request a display of a Web page stored on a Web server byissuing a URL request through the Internet to the Web in a known manner.

[0005] Since the Web utilizes standard protocols and a standardrendering engine, i.e. the rendering engine of the browser, the Web hasbecome ubiquitous. One of the primary applications of the Web has beendistribution of content in the form of documents. A “document”, as theterm is used herein, is any unit of information subject to distributionor transfer, including but not limited to correspondence, books,magazines, journals, newspapers, other papers, software, photographs andother images, audio and video clips, and other multimedia presentations.A document may be embodied in printed form on paper, as digital data ona storage medium, or in any other known manner on a variety of media.

[0006] However, one of the most important issues impeding the widespreaddistribution of digital documents, i.e. documents in forms readable bycomputers, via electronic means, and the Internet in particular, is thecurrent lack of protection of the intellectual property rights ofcontent owners during the distribution and use of those digitaldocuments. Efforts to resolve this problem have been termed“Intellectual Property Rights Management” (“IPRM”), “Digital PropertyRights Management” (“DPRM”), “Intellectual Property Management” (“IPM”),“Rights Management” (“RM”), and “Electronic Copyright Management”(“ECM”), collectively referred to as “Digital rights management (DRM)”herein.

[0007] In the world of printed documents, a work created by an author isusually provided to a publisher, which formats and prints numerouscopies of the work. The copies are then sent by a distributor tobookstores or other retail outlets, from which the copies are purchasedby end users. While the low quality of copying and the high cost ofdistributing printed material have served as deterrents to unauthorizedcopying of most printed documents, it is far too easy to copy, modify,and redistribute unprotected digital documents. Accordingly, some methodof protecting digital documents is necessary to make it more difficultto copy and distribute them without authorization.

[0008] Unfortunately, it has been widely recognized that it is difficultto prevent, or even deter people from making unauthorized distributionsof electronic documents within current general-purpose computing andcommunications systems such as personal computers, workstations, andother devices connected over communications networks, such as local areanetworks (LANs), intranets, and the Internet. Many attempts to providehardware-based solutions to prevent unauthorized copying have proven tobe unsuccessful. The proliferation of “broadband” communicationstechnologies (NII) will render it even more convenient to distributelarge documents electronically, including video files such as fulllength motion pictures, and thus will remove any remaining deterrents tounauthorized distribution of documents. Accordingly, DRM technologiesare becoming very useful.

[0009] Two basic schemes have been employed to attempt to solve thedocument protection problem: secure containers and trusted systems. A“secure container” (or simply an encrypted document) offers a way tokeep document contents encrypted until a set of authorization conditionsare met and some copyright terms are honored (e.g., payment for use).After the various conditions and terms are verified with the documentprovider, the document is released to the user in clear form. Commercialproducts such as Cryptolopes by IBM™ and by InterTrust's™ Digiboxes fallinto this category. Clearly, the secure container approach provides asolution to protecting the document during delivery over insecurechannels, but does not provide any mechanism to prevent legitimate usersfrom obtaining the clear document and then using and redistributing itin violation of content owners' intellectual property.

[0010] Cryptographic mechanisms are typically used to encrypt (or“encipher”) documents that are then distributed and stored publicly, andultimately privately deciphered, i.e. unencrypted, by authorized users.This provides a basic form of protection during document delivery from adocument distributor to an authorized user over a public network, aswell as during document storage on an insecure medium.

[0011] In the “trusted system” approach, the entire system isresponsible for preventing unauthorized use and distribution of thedocument. Building a trusted system usually entails introducing newhardware such as a secure processor, secure storage and secure renderingdevices. This also requires that all software applications that run ontrusted systems be certified to be trusted. While building tamper-prooftrusted systems is still a real challenge to existing technologies,current market trends suggest that open and untrusted systems such asPC's and workstations using browsers to access the Web, will be thedominant systems used to access copyrighted documents. In this sense,existing computing environments such as PC's and workstations equippedwith popular operating systems (e.g., Windows™, Linux™, and UNIX) andrendering applications such as browsers are not trusted systems andcannot be made trusted without significantly altering theirarchitectures. Of course, alteration of the architecture defeats aprimary purpose of the Web, i.e. flexibility and compatibility.

[0012] U.S. Pat. No. 5,715,403, the disclosure of which is incorporatedherein by reference, discloses a system for controlling the distributionof digital documents. Each rendering device has a repository associatedtherewith. Usage rights labels are associated with digital content. Thelabels include usage rights that specify a manner of use of the contentand any conditions precedent for exercising the manner of use. U.S. Pat.No. 5,052,040 discloses the use of a label prefixed to digital files sothat different users can have specific encryption capability and rightswith respect to the same file.

[0013] Two basic approaches have been taken to control the distributionof documents over the Web. The first approach is the use of subscriptionbased services in which the user is only granted access to content afterpaying a subscription fee. However, once the subscription fee is paidand the document is rendered by the browser, the user can copy, print,and modify the document, i.e. all control of the document by thepublisher is lost.

[0014] The second approach is to utilize proprietary formats wherein thedocument can only be rendered by a select rendering engine that isobligated to enforce the publisher's rights. Of course, this approachrequires the use of a single proprietary format and loses the ability tocombine plural popular formats and the richness of content associatedtherewith. Further, this approach requires the user to use a proprietaryrendering application that must be obtained and installed on the user'scomputer and requires development of the rendering application for eachformat to be rendered in a secure manner. Further, the documents must begenerated or converted using non-standard tools.

[0015] Further, there are various known mechanisms by whichfunctionality can be added to a standard rendering engine, such as a Webbrowser. For example, an ActiveX control can be automatically downloadedand executed by a Web browser. ActiveX is a set of rules for howapplications should share information and ActiveX controls can bedeveloped in a variety of programming languages, including C, C++,Visual Basic, and Java.

[0016] An ActiveX control is similar to a Java applet. Unlike Javaapplets, however, ActiveX controls have full access to the Windows™operating system. Microsoft™ has developed a registration system so thatbrowsers can identify and authenticate an ActiveX control beforedownloading it. Java applets can run on all platforms, whereas ActiveXcontrols are currently limited to Windows environments.

[0017] A scripting language called VBScript enables Web authors to embedinteractive elements in HTML documents to initiate a download andinstallation of ActiveX controls and other functions. Currently,Microsoft's Web browser, Internet Explorer™, supports Java, JavaScript,and ActiveX, whereas Netscape's Navigator™ browser supports only Javaand JavaScript, though its plug-ins can enable support of VBScript andActiveX. However, the availability of various plug-in and add-onsoftware for browsers further complicates the user experience andpresents a variety of problems in implementing a reliable DRM systemover the Web or other open networks.

[0018] VYOU.COM has developed a system for protecting intellectualproperty in documents distributed over the Web. The system includes asoftware plug-in, to the user's Web browser. The plug-in includes aproprietary rendering engine for the proprietary format in whichdocuments are represented and transmitted. Accordingly, documents mustbe reformatted into the proprietary format and the plug-in renderingengine for the appropriate final viewing format is used in place of thestandard browser rendering engine. This arrangement requires therendering engine for each format must be developed. Therefore, thissystem is difficult to implement and loses the advantages of the Web asan open architecture.

[0019] The proliferation of the Web, and its usefulness in documentdistribution, makes it desirable to apply DRM features to Web browsersand other standard rendering engines without requiring the renderingengines to be rewritten. However, conventional DRM technologies are noteasily adapted to use with Web browsers and other standard renderingengines because they require proprietary formats and rendering engineswhich contradict the open architecture of the Web. The inability tocontrol application programs, such as Web browsers, independently fromtheir rendering engines has made it difficult to apply DRM features overdistribution networks.

[0020] Another roadblock to implementing DRM systems over the Web is thefact that often the fees paid for proprietary documents, particularlyfor limited rights in proprietary documents are relatively small. Forexample, in many cases, the fees for limited rights in proprietarydocuments may be less that one dollar ($1.00) U.S. In such cases, theexpense associated with processing a credit card charge, includingaccess fees, transaction fees, and the like are relatively large ascompared to the entire document fee. For such relatively smalltransactions, often referred to as “micro-transactions,” the use of acredit card for the corresponding “micropayment”, i.e. relatively smallpayment, is not practical. Further, since each credit card transactionis processed as an individual charge, a customer purchasing a largevolume of documents in various transactions, will generate a largenumber of small transactions which is not efficient for credit cardtransactions.

[0021] Various proprietary solutions have been developed for handlingmicropayments, and other payments, over the Internet. For example,CyberCash™, Inc. and epayment Systems™, Inc. each provide suchsolutions. Also, Intellicent™ provides a specific solution formicropayments. However, these solutions are not integrated in a DRMenvironment.

SUMMARY OF THE INVENTION

[0022] An aspect of the invention is a method for controlling use ofcontent by validating a token. The method comprises receiving, at a userdevice, a challenge token from a first server, forwarding the challengetoken to a second server in association with a request for use ofcontent, analyzing a signature of the challenge token to determine anorigin of the challenge token, authorizing the request by a secondserver to use the content if the first server is related to the secondserver.

BRIEF DESCRIPTION OF THE DRAWING

[0023] The invention is described through a preferred embodiment and theattached drawing in which:

[0024]FIG. 1 is a block diagram of a document distribution systemutilizing DRM technology;

[0025]FIG. 2 is a schematic representation of a DRM system of thepreferred embodiment;

[0026]FIG. 3 is a flowchart of a method of operation of the preferredembodiment for causing the server to respond only to a protected client;

[0027]FIG. 4 is a flowchart of a method of operation of the preferredembodiment for accessing protected content;

[0028]FIG. 5 is a flowchart of a method of operation of the preferredembodiment for installing a security module;

[0029]FIG. 6 is a flowchart of a method of operation of the preferredembodiment for inactivating a security module;

[0030]FIG. 7 is a flowchart of a method of operation of the preferredembodiment for facilitating authentication of a client for multipleservers;

[0031]FIG. 8 is a flowchart of a method of operation of the preferredembodiment for permitting a service to control the user interface of aclient;

[0032]FIG. 9 is a block diagram of content having references to userinterface components;

[0033]FIG. 10 is a flowchart of a method of operation of the preferredembodiment for applying client-specific watermarks;

[0034]FIG. 11 is a flowchart of a method of operation of the preferredembodiment for aggegating transaction information;

[0035]FIG. 12 is a flowchart of a method of operation of the preferredembodiment for address obfuscation;

[0036]FIG. 13 is a flowchart of a method of operation of the preferredembodiment for using an asynchronous protocol for HTTP documenttransfer;

[0037]FIG. 14 is a flowchart of a method of operation of the preferredembodiment for dynamic certification of software;

[0038]FIG. 15 is a flowchart of a method of operation of the preferredembodiment for dynamic variable encryption;

[0039]FIG. 16 is a flowchart of a method of operation of the preferredembodiment for embedding security information in a document;

[0040]FIG. 17 is a flowchart of a method of operation of the preferredembodiment for determining usage rights based on a requesting URL;

[0041]FIG. 18 is a flowchart of a method of operation of the preferredembodiment for downloading necessary rendering applications; and

[0042]FIG. 19 is a flowchart of a method of operation of the preferredembodiment for time stamping validation tokens.

DETAILED DESCRIPTION

[0043] The invention is described below with reference to a preferredembodiment. It will be apparent that the invention can be embodied in awide variety of forms, some of which may be quite different from thoseof the disclosed embodiment. Consequently, the specific structural andfunctional from other users who wish to view a particular document.Clearinghouse 150 also collects payment information, such as debittransactions, credit card transactions, or other known electronicpayment schemes, and forwards the collected payments as a payment batchto distributor 120. Of course, clearinghouse 150 may retain a share ofthe payment as a fee for the above-noted services. Distributor 120 mayretain a portion of the batch payment from clearinghouse 150 fordistribution services and forward a payment (for example royalties) toauthor 110. Distributor 120 may await a bundle of user requests for asingle document before distributing the document. In such a case, asingle encrypted document can be generated for unencryption by all ofthe requesting users 130.

[0044] Each time user 130 requests (or uses) a document, an accountingmessage is sent to audit server 140 which ensures that each request byuser 130 matches with a document sent by distributor 120. Accountinginformation is received by audit server 140 directly from distributor120. Any inconsistencies are transmitted via a report to clearinghouse150, which can then adjust the payment batches made to distributor 120accordingly. This accounting scheme is present to reduce the possibilityof fraud in electronic document distribution and to handle anytime-dependent usage permissions that may result in charges that vary,depending on the duration or other extent of use. Audit server 140 andclearinghouse 150, in combination, can serve as transaction aggregator160 which functions to aggregate plural transactions over a period oftime, and charge distributor 120 in an appropriate manner to reduce theaccounting overhead of distributor 120. The model for electronicdocument distribution illustrated in FIG. 1 can be applied to theelectronic document distribution system of the preferred embodimentdisclosed herein. Further, content can include usage rights as describedabove.

[0045]FIG. 2 is a schematic representation of a computer architecture ofa document distribution system in accordance with a preferred embodimentof the invention. As noted above, the invention can be used inconnection with known models for effecting accounting and payment offees, such as use of a clearinghouse and an audit server. Further, theinvention can be used in connection with various commerce models.Accordingly, the apparatus for auditing distribution, effecting payment,and authoring a document is not described in detail herein and isomitted from the discussion of the preferred embodiment to simplifydescription thereof.

[0046] As illustrated in FIG. 2, digital content distribution system 200comprises distributor server 220, corresponding to distributor 120described above, and client computer 230, corresponding to user 130described above. Server 220 and client computer 230 can be generalpurpose computers programmed to accomplish the desired functions. Forexample, server 220 can be a standard server or workstation running theWindows NT™ operating system and including HTTP server software 226 suchas Apache™ or another HTTP server. Client 230 can be a personal computerrunning the Windows™ operating system. In the preferred embodiment,server 220 and client 230 are each coupled to communications network300, such as the Internet, or more specifically, the Web. Accordingly,client 230 includes browser 232 as a standard application program havinga rendering engine. Browser 232 can be any HTTP compliant browser, suchas Microsoft Internet Explorer™ or Netscape Navigator™. The phrase“standard application program”, as used herein, refers to anyapplication program designed to accomplish a task, such as documentcreation, viewing and editing, and having a rendering engine. Examplesof standard application programs include word processors, Web browsers,editors, viewers, spreadsheet programs, database programs, and the like.

[0047] Server 220 has a plurality of documents 222 stored thereon, inthe form of Web pages, for distribution. Documents 222 can be stored inan encrypted format. The term “encrypted”, as used herein, refers to anymechanism by which accessibility of content is partially or completelyprohibited, such as by use of asymmetric or symmetric encryptionalgorithms, scrambling algorithms, or the like. Server 220 also includesdigital rights management module 224, in the form of software, forstoring and managing usage rights associated with particular ones ofdocuments 222, users, and/or payment amounts or other conditions. Otherfunctions of rights management module 224 are described in greaterdetail below. Distributor server 220 can be part of a server farm orother group of computers, which can also include distributor server 220′as illustrated in FIG. 2.

[0048] Client 230 also has user interface (UI) module 234 and connectionmodule 236 each in the form of software and each adapted to attach tobrowser 232 without the need for modification of browser 232. Forexample, UI module 234 and connection module 236 can be in the form ofplug-ins, ActiveX controls, or in any form that allows attachment to therendering engine of browser 232 without the need for modifying the codeof browser 232. Such attachment is described in greater detail below. Incombination, UI module 234 and connection module 236 constitute asecurity module which is described in detail below. While securitymodule 237 is illustrated as residing in client computer 230, it willbecome clear that security module 237 can include client side componentsand server side components. For example, DRM module 224 described belowcan be a server side component of security module 237.

[0049] Rights management module 224 is a server side component that canstore labels of usage rights and identify which rights are associatedwith each document 222. The rights also can vary based on the identityof the user requesting access to document 222, any payment made by theuser through a clearinghouse or the like, and any other conditions. Forexample, the user may have the option of paying one fee to view document222 or a higher fee for viewing and printing the same document 222, asis well known. Rights management module 224 is also operative to deliverthe appropriate list of rights along with the document, viacommunications network 300, to connection module 236 of client 230 asdescribed below.

[0050] Connection module 236 can be a client side software componentwhich verifies the integrity of the environment of client 230 byverifying that UI module 234 is attached to browser 232, identifies theuser of client 230, i.e. the person requesting content, retrieves thedocument and the appropriate list of rights sent by rights managementmodule 224, and in appropriate circumstances, unencrypts any retrieveddocuments that are encrypted and generates any necessary signaturesand/or keys. UI module 234 can be a client side component that monitorsrequests from the user to access content of documents 222 and eithergrants or denies the request based on the list of rights retrieved byconnection module 236. Further, UI module 234 can disable specifiedfunctions of browser 232 and the operating system of client 230 based onthe list of rights in the manner described below, by interfacing withthe operating system API and intercepting and redirecting commands forexample. Connection module 236 verifies that the industry standardrendering engine running in the environment of client 230 has not beentampered with or otherwise compromised in a way that may allow the userto access protected content in a way that bypasses UI module 234.

[0051] The invention can be implemented in connection with knownclient/server networking architectures, such as the Web, withoutmodifying obviating, or bypassing the standard client software, serversoftware, and rendering engines. Rights management module 224 isinstalled in server 220 along side the existing server software 226. Asnoted above, rights management module 224 identifies which rights areassociated with documents 222 existing on server 220 or later stored onserver 222. For example. Rights management module 224 can have aprogrammable database, lookup table or the like including the variousrights associated with each document 222 and other variables, such asthe identity of the user and the payment made by the user, in a wellknown manner. Rights management module 224 further interfaces with theoperating system API of server 220 to cause server software 226 to onlyrespond to connections from client(s) 230 having the proper componentsof security module 237, such as connection module 236 and UI module 234.Also, rights management module 224 serves as in interface with database225 described below.

[0052] For example, once rights management module 234 is installed theprocedure illustrated in FIG. 3 is accomplished. In step 302, a new DRMstart Web page, or other secure interface display, is created whichreferences UI module 234 and the existing server start Web page. In step304, the various Web pages of a Web site on server 220 can be placed ina directory having a random label or any unknown directory. In step 306,rights management module 224 is programmed to include a pointer to thisdirectory and, in step 308, rights management module 224 encrypts theURL of this directory. In step 310, the start DRM Web page is modifiedto reference UI module 235 which can instruct connection module 236 tounencrypt the encrypted URL to permit access to original start page andthe rest of the Web site. If client 230 does not have UI module 234 andconnection module 236, the URL cannot be unecrypted and thus the Website on server 220 cannot be accessed.

[0053] Alternatively, connection module 236 can generate a signature andsend the signature to server 220 with any URL request to server 220.Access to the Web site on server 220 will only be granted if thesignature is present and valid. In this alternative, rights managementmodule 224 can include code to validate the signature.

[0054] When a user of client computer 230 attempts to access server 220having rights management module 224, rights management module 224verifies if all required components of security module 237 UI module234, such as are installed on client 230 as described above. If not,instructions in the DRM start Web page in the form of a java applet,ActiveX control, or the like, instruct browser 232 to download andinstall UI module 234 in the manner described in greater detail below.Download can be accomplished from server 220 or another server coupledto communications network 300. Such download and installation can beaccomplished in a known manner using conventional mechanisms, and theuser can be prompted to authorize installation and to enter othernecessary information, such as where to store the installation files.Connection module 236 can be imbedded in UI module 234 and downloadedand installed simultaneously or through a separate download andinstallation process. Of course, if UI module 234 is detected asinstalled on server 230, the installation step can be skipped. If UImodule 234 is not installed on client 230, and the user does notauthorize such installation, access to documents on server 222 isprohibited, or limited only to documents specified as being freelydistributable.

[0055] As noted above, UI module 234 and connection module 236 are in aform in which they can be attached to browser 232 without the need tomodify the code of browser 232. The term “attached” as used herein withrespect to the modules, refers to software modules that can be combinedor coupled with browser without modifying the code of browser 232. Forexample, UI module 234 and connection module 236 are in the form ofplug-ins, in the case of Netscape Navigator™ or ActiveX Controls in thecase of Internet Explorer™. The mechanisms for developing and installingsuch components are well known.

[0056] A procedure for accessing protected content, in the form ofdocuments 222, stored on server 220 is illustrated in FIG. 4. In step402, the DRM start Web page is accessed through its URL in a knownmanner. In step 404, the DRM start Web page directs UI module 234 to theoriginal start page or pages referenced by the DRM start Web page usingone of the methods described above. In step 406, UI module 234 createsanother instance of the rendering engine of browser 232, loads theoriginal start Web page, and instructs the operating system to displaythe new instance in a browser window, using known techniques. The newinstance is directed, by UI module 234, to retrieve content from server220 through connection module 236 in step 408. In other words, in thepreferred embodiment, UI module 234 intercepts commands from browser 232and redirects them through connection module 236. UI module 234 caninstruct the new instance to utilize a secure asynchronous protocolthrough connection module 236 as describe in greater detail below.Therefore, UI protection is validated and all user interface events, canbe intercepted and controlled in step 410. For example, when the userinitiates a “print” or “copy” command through the standard userinterface of browser 232, UI module 234 intercepts the request and onlypermits response if the set of rights received by connection module 236permits the requested function to be carried out.

[0057] More specifically, when connection module 236 receives a requestfrom the rendering engine of browser 232, connection module 236validates that the rendering engine is protected by UI module 234, i.e.UI module 234 is attached, and that the rendering engine has not beentampered with or otherwise compromised. If so, connection module 236permits connection to rights management module 224 of server 220 andnegotiates permission to retrieve the original start Web page on server220 and the set of rights for the user for the Web page. Rightsmanagement module 224 then initiates a connection between serversoftware 226 of server 220 and connection module 236 of client 230. Theconnection can be established using any protocol, such as HTTP or HTTPSor any other standard or proprietary connection protocol.

[0058] The requested document 222 is then retrieved and delivered toconnection module 236 which unencrypts document 222, if encrypted onserver 220, and delivers the document in unencrypted form to the newinstance of the rendering engine of browser 232 along with the set ofrights associated with the document. Once again, the contents of the setof rights may be determined based on the document, the user's identity,a payment made by the user, or any other appropriate parameter.Connection module 236 then transmits the set of rights to UI module 234which limits the functions available to the user based on the set ofrights by controlling the new instance of the rendering engine ofbrowser 236 as described above.

[0059] The content of the document is now viewable in a window ofbrowser 232 as any other Web page would be. However, browser 232 doesnot have direct access to the Web page of the document because browser232 is “wrapped” by UI module 234 or other components of security module237 as will be described below. UI modules 234 prevents browser 232 fromperforming any prohibited functions outside of the scope of the set ofrights for the document.

[0060] The preferred embodiment utilizes a standard rendering engine ofan application program, such as a browser, a word processor, or anyother application or display program. The preferred embodiment achievesthis by interfacing with the application and standing between theapplication and the document to control access to the document.Accordingly, a separate proprietary rendering engine for each documentformat is not required. Further, any data format supported by theapplication will be supposed by the invention without modification. Itcan be seen that the preferred embodiment permits DRM systems to beadapted to standards, such as TCP/IP and the use of browsers to renderHTML. Further, the preferred embodiment facilitates variousfunctionality that permits DRM to be applied to systems in a manner thatis transparent to the user. Several examples of methods of operation ofdocument distribution system 200 are described below.

[0061] In the first example, client computer 230 initially does not haveall required components of security module 237 installed therein. Asillustrated in FIG. 5, client computer 230, makes a request ofdistributor server 220 for one or more documents 222 in step 502.Distributor server 220 analyzes the request and based on a lack ofsignature information within the request (indicating that components ofsecurity module 237 are not loaded in client computer 230), sends aresponse to client computer 230 to load the requisite components ofsecurity module 237 in step 504. As noted above, security module 237functions to enforce usage rights in client computer 230. The responsesent in step 504 is specific to the type of client requesting thecontent. If the client software on client computer 230 is a Web browser,for example, distributor server 220 will send a response that is a Webpage including an executable software component. For example, thesoftware component can be in a standard form such as Java Script orActive Server Pages. In addition the response, a Web page in thepreferred embodiment, can include a copy of the unsigned request forcontent sent in step 502.

[0062] Client computer 230 receives the Web page and executes thesoftware component that includes information about where to get thecomponents of security module 237, in step 506, to request a copy of thecomponents. Client computer 230 receives and installs the components ofsecurity module 237 in step 508. Security module 237 is configured toautomatically begin to run in browser 232, using the mechanism describedabove for example. In step 510, security module 237 then reads the copyof the original request for content 222 contained in the Web page whichinvoked security component 237 and resubmit the request to distributorserver 220 with a digital security signature. In step 512, distributorserver 220 receives the signed request and validates the signature onthe request. Because this request is properly signed by security module237, distributor server 220 delivers the document 222 to security module237 installed on client computer 230 for rendering by browser 232 inaccordance with usage rights and conditions associated with the contentof document 222. The method illustrated in FIG. 5 provides forauto-engaging security control to seamlessly and transparently providethe client with the software that the user needs to render content 222in a secure manner. Security module 237 can include a software agentthat is operative to analyze any rendering engine or other components ofclient computer 230, in step 508, to validate that the clientenvironment is secure. Security module 237 can resubmit the request, instep 510, after such validation.

[0063]FIG. 6 illustrates another example of a method of operation of thepreferred embodiment. In step 602, security module 237 is directed toretrieve a document 222 from distributor server 220 server. In thisexample, document 222 is “clear content,” i.e., is not encrypted orotherwise obscured or limited and does not have any use restrictions.Document 222 is returned by server 220 to security module 237 in step604. Because document 222 is not signed, or encrypted, or otherwisemarked as content that needs to be handled by security module 237,security module 237 recognizes that it is no longer required. In step606, security module 237 notifies browser 232 that browser 232 shouldrequest document 222 directly by sending the original request forcontent to server 220. Security module 237 then removes itself as arunning component, i.e., inactivates, in step 608 to preserve resourcesof client computer 230. In step 610, browser 232 then resubmits therequest for document 222 that was originally sent by the security module237. Distributor server 220 then delivers documents 222 directly tobrowser 232 in step 612.

[0064] In order to maintain security and enforce usage rights, allrequests for content are initially made through security module 237.However, when the request returns content that does not requiresecurity, security module 237 becomes a potential liability because itutilizes computer resources. In this example, if security component 237is not needed, it is removed from a running state.

[0065] System 200 can use PKI encryption technology or any otherencryption, ciphering, or watermarking technology. Of course, eachtechnology requires that a client making a request for content beidentified as an authorized user. A digital certificate or signature canbe used for identification purposes. In other words, an attachment to anelectronic message used for identification purposes is sent with amessage. The most common use of a digital certificate or signature is toverify that a user sending a message is who he or she claims to be, andto provide the receiver with the means to encode a reply, e.g., anencryption key. An individual wishing to send an encrypted message canapply for a digital certificate from a Certificate Authority (CA). TheCA issues an encrypted digital certificate containing the applicant'spublic key and a variety of other identification information. The CAmakes its own public key readily available, through the Internet forexample. The recipient of an encrypted message uses the CA's public keyto decode the digital certificate attached to the message, verifies itas issued by the CA and then obtains the sender's public key andidentification information held within the certificate. With thisinformation, the recipient can send an encrypted reply. The most widelyused standard for digital certificates is X.509.

[0066] This identification process can be cumbersome when repeated ateach server from which content is requested. FIG. 7 illustrates anotherexample of a method of operation of the preferred embodiment in whichthe identification procedure at plural servers is expedited.

[0067] As illustrated in FIG. 7, client computer 230 requests document222 from distributor server 220 in step 702. Assuming that PKIencryption schemes are used, the request can be in the form of“PrivateClient[request]” in which the request is encrypted with aprivate key of client computer 230. Distributor server 220 looks at thesignature of the request and recognizes that the request is not from anauthenticated client and generates a unique “challenge” token which isreturned to client computer 230 in step 704. In the preferredembodiment, the challenge token can be in the form of“PrivateServer[PrivateClient[request]]” in which the original encryptedrequest is encrypted again using the private key of distributor server220.

[0068] Client computer 230 answers the challenge taken by transformingthe challenge in a unique way, i.e., signing the challenge token, instep 706. For example the transformation can be in the form ofencryption of the challenge token with the public key of distributorserver 220. In such a case, the transformation will be in the form of[PublicClient[PrivateServer[PrivateClient[request]]].” Client computer230 then resubmits the request to the distributor server 220 with thetransformed challenge token in step 708. Distributor server 220establishes authentication with the client by recognizing thetransformation. i.e. recognizing the challenge token as its own, andreturns the requested document 222 in step 710.

[0069] In many cases, distributor server 220 is part of a server farm orother set of related computers as noted above. Therefore, there is noguarantee that the server that gets the next request for this sessionwill in fact be the same server that generated the “challenge” token.For example, the next session request may be received by distributorserver 220′. When client computer 230 sends another request reusing thesame challenge token and the request is received by distributor server220′, in step 712, distributor server 220′ looks for the signature ofthe challenge token, and finds that the signature belongs to distributorserver 220, in step 714. Since distributor server 220 has a trustedrelationship with distributor server 220′, distributor server 220′ willhonor the challenge token of distributor server 220. In particular,distributor server 220′ evaluates the transformation of the challengetoken performed by the client and authenticates the client byidentifying server 220 as the creator of the challenge token. In step716, content 222′ is delivered from distributor server 220′ to clientcomputer 230.

[0070] In this method of operation a token supported by other relatedservers is honored by a server receiving a request. In order to simplifythe process, keys are not exchanged again. The approval of a previouskey exchange with a related server is used for any other server in agroup of related servers to speed up the process of authentication.

[0071] As noted above, the use of a standard rendering engine presentssignificant complications for DRM systems. For example, when using abrowser as the rendering engine, the standard user interface includescopy and print commands and other commands not necessarily compatiblewith DRM systems. It is known to disable such commands in which casemost GUIs, such as the Windows GUI, will shadow the menu selectionscorresponding to disabled commands. However, this is often confusing andnot ascetically pleasing. Further, it may be desirable to providecontent specific menu selections, such as choices of usage rights andconditions for exercise thereof, such as fees to be paid. Further, acontent vendor may want to present a proprietary branded user interfaceor a user interface that is consistent with other vendors. Also, it maybe desirable to highlight menu selections, such as a print button, undercertain circumstances.

[0072]FIG. 8 illustrates a method of operation of the preferredembodiment which permits content specific toolbars to be displayed asthe user interface of browser 232. Documents 222 are stored ondistributor server 220, as described above, in a form compatible withthe rendering application, a Web page in the preferred embodiment.Documents 222 are illustrated in detail in FIG. 9 and include referenceA to software component 220 a and reference B to description of abrowser toolbar and UI 220 b. Software component 220 a can be in theform of a Java applet, an Active X control, or the like. As the contentis rendered, the reference to the software component is identified bythe browser i.e. ActiveX Control, Java applet.

[0073] Referring to FIG. 8, browser 232 requests document 222 in step802. Browser 232 attempts to render document 222 and follows reference Ato thereby execute software component 220 a in step 804. Softwarecomponent 220 a then looks at content 222 that invoked it and identifiesreference B to description of toolbar and UI 220 b in step 806. Softwarecomponent 220 a then is operative to build a platform/browser specifictoolbar and UI based on description 220 b in step 808. In step 810,software component 220 a removes or hides the standard browser UI andtool bar and replaces them with those built in step 808. This method ofoperation permits the Web site (distributor for server 220 in this case)to dictate the navigation's motif, look, and appearance and thus tailorthe user's browser to the site, customizing buttons, colors, patterns,animations, menus, and tool bars.

[0074]FIG. 10 illustrates another manner of operation of the preferredembodiment in which a client-specific, or even instance specific,watermark can be applied to content for security and tracking purposes.The concept of digital “watermarking” is well known generally and allowscontent owners to imbed information within graphics and audio files thatcan be used to identify the owner's rights to these works. The term“digital watermark” is derived from the traditional watermarks thatexist in high-quality letterhead and certain currency. Traditionalwatermarks typically are not apparent to the reader, but, when held tothe light, reveal the name or logo of the paper's manufacturer or theentity using the letterhead. Similarly, digital watermarks also servethe purposes of identifying quality and assuring authenticity. A graphicor audio file bearing a digital watermark can contain informationrelating to the content owner or other information. Digital watermarksmay be only perceptible under certain conditions, such as when contentis printed in an unauthorized manner. In graphic images, for example,digital watermarks alter the image to provide digital informationsupplied by the party who imbedded the watermark. The watermarks may beviewed with stand-alone or plug-in software and can reveal, for example,a unique identification code that can be traced to the copyright owneror more complete copyright ownership information.

[0075] As illustrated in FIG. 10, client computer 230 requests document222 from distributor server 220 over communications channel 300 in step1002. Distributor server 220 delivers document 222 to security module237 in step 1004. Note that document 222, as delivered to securitymodule 237, may or may not have a watermark embedded therein. In step1006, security module 237 delivers document 222 to an instance of therendering engine, browser 232 in the preferred embodiment, for renderingin the manner described above. Security module 237 then usesinstance-specific information relating to the instance of the renderingengine used to render content 222 to apply a client-specific watermarkto the window that the instance of the rendering engine uses in step1008. The client-specific watermark can be applied using any techniquesor algorithms for watermarking. Also, the client-specific watermark canbe applied in addition to an existing watermark. The client-specificwatermark data can be stored or generated in any manner.

[0076] In either case, because the watermark is applied on the client,it can be unique to that client, and thus be traceable. Distributorserver 220 can deliver identical document 222 to all clients (thusminimizing server side performance impact). The client then applies aunique watermark using, for example, translucent windows to the image.If the consumer of the content then uses screen capture or anotherunauthorized mechanism to capture the content, the captured content isthen watermarked with an ID that is unique to that user for tracking andenforcement purposes.

[0077]FIG. 11 illustrates a manner of use of the preferred embodiment inwhich transaction payments are easily aggregated. In step 1102 clientcomputer 230, prior to installation of the requisite components ofsecurity module 237, requests document 222 from distributor server 220.In step 1104, distributor server 220 then informs client computer 230that document 222 is protected and client computer 230 needs to havesecurity module 237 to render document 222, and where security module237 can be acquired. In this case, security module 237 can be acquiredfrom a computer associated with transaction aggregator 160 (See FIG. 1).In step 1106, client computer 230 requests the requisite components ofsecurity module security module 237 from transaction aggregator 160 byopening a session with the computer associated with transactionaggregator 160. In step 1108, transaction aggregator 160 requests andcollects various user information including billing information and thelike for example in a conventional manner.

[0078] Transaction aggregator 160 generates a unique security module 237with a hidden unique public private pair or other indicia of theidentity of client computer 230, and returns security module 237 toclient computer 230 in step 1110. Security module 237 creates aprotected instance of browser 232, or other 3^(rd) party renderingapplication, enforces access protection around it, and instructs it toretrieve and render protected content 222 from distributor server 220 instep 1112. Distributor server 220 recognizes document 222 is beingrequested by a rendering engine that has been protected with securitymodule 237. And returns document 222.

[0079] The protected rendering application, e.g. browser 232 withsecurity module 237 attached, informs security module 237 that it isabout to render document 222. In step 1114, security module 237 analyzeswhat the digital rights are associated with document 222, and records anappropriate charge back to transaction aggregator 160. Transactionaggregator 160 tracks many small transactions performed against manyforms of content accessed by this instance of a public private key, thenaggregates them into a single charge periodically to a financialinstitution or other party associated with the indicia in securitymodule 237.

[0080]237 decrypts the location of the content referenced by the Webpage and requests document 222 from the secure location in step 1212.The content is delivered to security module 237 which creates aninstance of a protected rendering engine, e.g. browser 232 in thepreferred embodiment, and renders document 222 in step 1214.

[0081] The method of operation described above does not require a serverside executable and thus is an inexpensive way to provide adequate,while not necessarily maximum, security. In this example, the content isstored in a location having and address determined by a random number(or a pseudo-random number), for security purposes. Then, when the userinitiates a transaction, the user is presented with an HTML page havingthe location in an encrypted form. The security component decrypts thelocation and the client never discovers the location.

[0082]FIG. 13 illustrates another method of operation of the preferredembodiment which utilizes relative addressing for security. In step 1302web browser 232 of client computer 230 requests content from distributorserver 220. Distributor server 220 recognizes that the content requestis not coming from an appropriate security module 237 (by the lack of aproper signature for example), so it instructs client computer 230 toload the requisite components of security module 237 in step 1304. Instep 1306, security module 237 spawns a child HTML rendering engine,i.e. instance of browser 232, inside the existing instance of browser232 so that it can have full control of the child HTML rendering engine.Security module 237 then instructs the child instance to retrievecontent through an asynchronous protocol installed in security module237 instead of through ordinary HTTP protocol and addressing in step1308. For example, the asynchronous protocol can be HTML with Active Xcontrols embedded therein to establish a secure authenticatedcommunication channel. The asynchronous protocol can direct browser 232to retrieve content through another Web site that includes filteringtechnology to prevent access from unwanted or unauthorized users.Document 222 is rendered in step 1310.

[0083] For example, the asynchronous protocol can send the address ofthe user to a third party for verification that the user is wanted andauthorized. The asynchronous protocol can cause the child instance ofbrowser 232 can request the top level HTML page via a designated secureWeb site. After the top level page loads, the child instance can use anaddress prefix to retrieve all of the component parts of the page.Unprotected content can be retrieved via standard HTTP.

[0084] Generally, security is handed to HTML for rendering. However, inthis example, content is retrieved using a proprietary asynchronousprotocol. Therefore, a single instance of an HTML rendering engine canbe used to “pull” compound pieces of content. As an example, standardHTML rendering can be used to access a start Web page containing anActive X control in it. The control spawns a child rendering enginewhich retrieves content through a specified server, which in turnaccesses the server side, which includes the filtering technology or thelike. Note that a Web page (a compound document) has references to otherfiles and images. Conventionally, only the top level (HTML page) isprotected, and the references are not protected. However, in thisexample, since requests are handled through a secured server, both thetop level and the references are secure.

[0085]FIG. 14 illustrates another method of operation of the preferredembodiment. This method provides security by prohibiting the loading ofcode, such as plug-ins and Dynamic Link Libraries (DLLs), into therendering engine unless the code is certified as not compromisingsecurity. This method recognizes that certification can be a dynamicprocess that should permit users to use certified software immediatelyupon certification.

[0086] In step 1402 security module 237 of client computer 230 loads aninstance of a rendering application, browser 232 in the preferredembodiment. Browser 232 requests to load a third party add in program,such as DLL, in step 1404. Security module 237 intercepts the requestand querys local database 225 including a list of trusted certifiedthird party add in programs in step 1406. If security module 237 doesnot find the third party program that is attempting to load, securitymodule 237 contacts a trusted server to update its database of trustedthird party programs that are certified in step 1408. If the third partyprogram is found in the updated list, security module 237 permits theloading of the third party program into the rendering engine in step1410. If the determination in step 1406 is that the program is certifiedby being listed in database 225, the method goes directly to step 1410.If the determination in step 1408 is that the program is not in theupdated database as being certified, loading is prohibited in step 1412.

[0087] Whenever the rendering application wants to load any executablecode, it should be approved, i.e., certified, to avoid compromisingsecurity. If at the time of shipment of the security component a thirdparty product is not ready for certification, it cannot be included inthe approved list in the security module. If the program is approvedlater, the signature of the program will be compared to a list updatedby logging onto to a server having and updated certification database,data base 225 for example.

[0088]FIG. 15 illustrates a method of operation of the preferredembodiment which is well suited for the transfer of content in the formof video or other large files. It is known to encrypt only portions ofdata to reduce overhead and data transfer speed while still providing alevel of security. However, in the method illustrated in FIG. 15, thepercentage of encryption of a data stream is adaptive based on networklatency, connection speed and other factors. In step 1502, document 222is requested by client computer 230. Distributor server 220 determineswhat percentage of encryption to use by examining a database, usagerights, or other indication of encryption associated with document 222in step 1504. Such information can be stored in digital rights managersmodule 2. For example, the indication of encryption can specify thatencryption be greater than a specified percentage or in a range ofspecified percentages.

[0089] In step 1506, distributor server 220 monitors various conditionsrelated to data transfer, such as the files size of document 222,network latency, communication speed, and the like in a known manner. Instep 1508, distributor server 220 encrypts portions of document 222based on the conditions monitored in step 1506 and the encryption amountdetermined in step 1504. Steps 1506 and 1508 are conducted continuouslyor iteratively until all of document 222 has been transferred. In step1510, security module 237 decrypts the content and delivers it to therendering application, i.e. browser 232 in the preferred embodiment.

[0090] A variable portion (percentage) of a data stream can beencrypted. Content data can be divided by time intervals or based on thebyte size. For example, 10 bytes encrypted, and 90 bytes not-encrypted.The percentage of encryption can be adaptive. That is, depending on thedata file size and other conditions, at different times, the percentageof encryption can vary between values specified to speed up the process.

[0091] It is known to embed signatures and other security information inthe body of an HTTP document. However, such a practice requires specialsecurity tags and is difficult to manage since the security informationmust be parsed out of the document. However, the method of operation ofthe preferred embodiment illustrated in FIG. 16 simplifies thisoperation by using only the header of an HTML document for conveyingsecurity information.

[0092] In step 1602, browser 232 that is regulated by security module237 requests document 222 from distributor server 220 and securitymodule 237 opens up a standard HTTP or HTTPS connection to distributorserver 220. In step 1604, distributor server 220, functioning as astandard HTTP server, retrieves or builds document 222 for downloading.In particular, digital rights management module 224 or another securitymodule component of distributor server 220 authenticates the requestingclient by analyzing security information embedded in the headers of theHTTP request and builds a standard HTTP reply.

[0093] In step 1606, distributor server 220 inserts security informationinto the headers of the HTTP reply. For example, the securityinformation, such as a signature can be an attribute of the <Header>tagin an HTML document as set forth below:

[0094] <Header>signature=13490680486724869 MY BOOK <Header/>

[0095] In the example above, the title of the HTML page is “MY BOOK”which will be rendered in accordance with standard HTML rules. Thesignature is a number as an attribute of the header and will not berendered but can be culled for security purposes. In step 1608, thereply is sent to security module 237 of client computer 230. In step1610, security module 237 analyzes the security information in the replyheader and passes content of document 222 to browser 232 for renderingin accordance with the usage rights-described by or associated with thesecurity information.

[0096] Since all of the security information is contained in the header,the resulting DRM system is less intrusive and easier to manage. Also, anew security tag schema or other specification is not necessary. Thesecurity component need only know to look in the header to get securityinformation.

[0097] Often content and usage rights are dynamic. For example, thecontent may change over time and the usage rights may change over timeand may be dependent on where the request for content comes from. Forexample, a company may want to let an employee print or save a documentif the document is requested from an on-site, or otherwise secure,computer. However, the same employee requesting the same document fromhome may only be permitted to view the document. FIG. 17 illustrates amethod of use of the preferred embodiment that provides both address andURL filtering to address these issues.

[0098] In step 1702, client computer 230 having security module 237,requests secure document 222. In step 1704, distributor server 220gathers information from either static or dynamic sources of content 222and builds the response in a known manner. After the response has beenbuilt, a server side component of security module 237 accesses adatabase 225 that maps regular expressions of URL's to usage rights instep 1706. Server side component of security module 237 inserts therights associated with the reply based on the URL of the request byselecting the rights corresponding to the URL in database 225 in step1708. The reply is then sent to client computer 230 for rendering of therequested content 222 in accordance with the inserted usage rights undercontrol of client side component of security module 237.

[0099] Since both URL addressing and directory addressing are used,dynamic content and content that is best identified by incoming requestURL's can be handled appropriately. Directories are filtered in order toprovide a high level of confidence that content stored on thedistributor server 220 as a file cannot be delivered to an unauthorizeduser no matter what URL is used to reach the file stored on the server.By using both types of filters, the content owner has flexibility indetermining what content should be protected and to what degree.Further, putting security content in the header of an HTML documentpermits dynamic content to be handled easily because the body of thecontent does not need to be modified for security and thus permitsdynamic content to be used to build a document on the fly.

[0100] Another problem often encountered in rendering content,particularly when distributing content over the Internet or othernetworks, is that the user may not always have the proper renderingapplication. For example, when downloading a PDF file, content providerswill often warn the user that Adobe Acrobat Reader™ is required and mayeven provide a link to download the software. If the user does notdownload the software, they cannot render the content. However,downloading the software requires significant action on the part of theviewer, such as clicking on the link, choosing a directory for download,executing the installation software, and the like. In many cases, theuser will choose not to download the content to avoid the cumbersomeprocess of installing the proper rendering application. In DRM systems,the need for multiple rendering applications raises security issues ifthe security component is not attached to a newly installed renderingapplication.

[0101]FIG. 18 illustrates a manner of use for providing the properrendering applications in a manner that is transparent to the user. Instep 1802, client computer 230 requests document 222 that is of a fileformat that cannot be rendered by browser 232. In step 1804, document222 is packaged as a file of the same format but is “disguised” as anHTML file. For example, the Windows™ operating system identifies filetypes by file extension. In such a case, the file, for example a PDFfile, can be named with an “HTM” extension to be identified as an HTMLfile by client computer 230.

[0102] In step 1806, the file is downloaded to client computer 230 andthe user “opens” the file which client computer 230 recognizes as anHTML file. Accordingly, browser 232 is launched as the default HTMLviewer. In step 1808, browser 232 begins to render the HTML and finds areference to an embedded application, like an ActiveX control or Javaapplet. The browser embedded application causes 232 to check and findsthat the referenced application is not installed on client computer 230in step 1810. The browser follows the reference in the file to downloadthe application in step 1812 and the application is installed on clientcomputer 230 and attached to security module 237 as described above. Theapplication, now used as the rendering application is directed bysecurity module 237 to retrieve the content from within the HTML fileand render the content in step 1814.

[0103] The drawback of distributing a new file type extension is that ifthe user receives one of your data files and there is no registeredapplication to handle the request, then the user cannot continue workingwith the content or must manually install a new application. However, ifthe new file type is packaged inside an HTML file the Web browser thenloads the HTML file and automatically finds the code (JavaScripts,etc.). If the code sees a registered application on the client platformit passes the contained data to that client application. If it does notfind an application to handle the data type, it calls upon the browserto navigate to a site that downloads the appropriate renderingapplication.

[0104] Another security issue when distributing content over a network,such as the Internet, is the possibility that hackers will interceptmessages and “crack” encryption routines to obtain access to protectedcontent. However, circumventing encryption often requires a relativelygreat deal of time (several seconds for example) because of the need toexecute complex software algorithms or generate random numbers. FIG. 19illustrates a method of operation of the preferred embodiment in whichthe risk of encryption circumvention is reduced by creating tokens thatexpire after short period so time.

[0105] In step 1902, client computer requests secure content 222.Assuming that a server side security component of security module 237has not authenticated client computer 230, distributor server 120generates a challenge token, that is time stamped, in step 1904. Clientcomputer 230 receives the token and uses its non-unique public keyprivate key pair to add a request and sign it in a known manner in step1906 and returns the signed token to distributor server 220. Uponreceipt of the signed token, distributor server 220 verifies thesignature of client computer 230 and checks to see when the token wasgenerated by examining the time stamp in step 1908. If the token wasgenerated more than a predetermined time period, 0.5 seconds forexample, before being received in a signed fashion, the token is nolonger valid and access to content 222 will be denied, in step 1910,even if the signature is otherwise correct.

[0106] The time stamp can indicate how long the signature is valid(usually a very short time that permits proper signature but does notpermit encryption circumvention) or the time that the signature wascreated. If an unauthorized party intercepts the message, and tries toimitate the message at a later time, then the signature will haveexpired and will not be valid.

[0107] The invention can be implemented over any type of communicationsNetwork, such as the Internet, a local area network (LAN), a wide areanetwork (WAN), direct computer connections, or the like, using any typeof communication hardware and protocols. Any type of hardware orcombination of hardware can be used for the various clients and servers.Accordingly, the terms “client” and “server” as used herein, can referto any type of computing device or data terminal, such as a personalcomputer, a portable computer, a dumb terminal, a thin client, a handheld device, a wireless phone, or any combination of such devices. Thevarious clients and servers can be a single computer at a singlelocation or multiple computers at a single or multiple locations. Forexample a server may be comprised of a plurality of redundant computersdisposed in co-location facilities at various locations to facilitatescalability. There can be any number of clients and any number ofservers. The client can physically be located on the same hardware asthe server.

[0108] Any appropriate server or client software can be used and anycommunication protocols can be used. Communication can be accomplishedover electric cable, fiber optic cable, or any other cable, or in awireless manner using radio frequency, infrared, or other technologies.The various information can be stored in any format and thus the term“database” as used herein refers to any collection of information suchas a database file, a lookup table, or the like. The documents can be ofany type and can contain any type of content, such as text, audioinformation, video information, or combinations of plural types ofcontent. The portions of the invention described above that aredescribed as software components could be implemented as hardware.Moreover, while certain functional blocks are described herein asseparate and independent from each other, these functional blocks can beconsolidated and performed on a single general-purpose computer, orfurther broken down into sub-functions as recognized in the art. The setof rights can be one or more rights or rules governing use of thedocument, can be in any appropriate form, and can be based on variousparameters such as the document type, the user's identity, a payment bythe user, and the like. The various software modules can be located onthe client or the server. For example, the security module can includeone or plural components on the server side and/or on the client side asappropriate to accomplish the various functions disclosed above.

[0109] While a preferred embodiment of the invention has been describedin detail above, it should be recognized that other forms, alternatives,modifications, versions and variations of the invention are equallyoperative and would be apparent to those skilled in the art. Thedisclosure is not intended to limit the invention to any particularembodiment, and is intended to embrace all such forms, alternatives,modifications, versions and variations. Accordingly, the true scope ofthe invention is defined by the appended claims and legal equivalents.

What is claimed is:
 1. A system for controlling use of content byvalidating a token comprising: means for receiving, at a user device, achallenge token from a first server; means for forwarding the challengetoken to a second server in association with a request for use ofcontent; means for analyzing a signature of the challenge token todetermine an origin of the challenge token; and means for authorizingthe request by a second server to use the content if the first server isrelated to the second server.
 2. The system of claim 1, where the firstserver and the second server share an identifiable signature that isassociated with the challenge token and represents a trustedrelationship.
 3. The system of claim 1, said means for analyzing asignature comprises means for evaluating a transformation of thechallenge token performed by the user device.
 4. The system of claim 2,wherein a plurality of signatures are shared and known between aplurality of first and second servers.
 5. The system of claim 4, whereinany of the plurality of associated servers can identify an authorizedsignature from any other of the associated servers with said means forauthorizing.
 6. The system of claim 1, wherein the challenge token froma first server is generated in response to a previous request for use ofcontent.
 7. The system of claim 1, further comprising means fordelivering content from the second server to the user device.
 8. Thesystem of claim 1, further comprising means for establishing trustedrelationships between a plurality of servers.
 9. A method of controllinguse of content by validating a token comprising: receiving, at a userdevice, a challenge token from a first server; in association with arequest for use of content, forwarding the challenge token to a secondserver; analyzing a signature of the challenge token to determine anorigin of the challenge token; and the second server authorizing therequest to use the content if the first server is related to the secondserver.
 10. The method of claim 9, where the first server and the secondserver share an identifiable signature that is associated with thechallenge token and represents a trusted relationship.
 11. The method ofclaim 9, wherein said analyzing step comprises evaluating atransformation of the challenge token performed by the user device. 12.The method of claim 10, wherein a plurality of signatures are shared andknown between a plurality of servers.
 13. The method of claim 12,wherein any of a plurality of associated servers can identify anauthorized signature from any other of the associated servers toauthorize a request.
 14. The method of claim 9, wherein the challengetoken is generated in response to a previous request for use of content.15. The method of claim 9, further comprising delivering content fromthe second server to the user device.
 16. The method of claim 9, furthercomprising establishing trusted relationships between a plurality ofservers.